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SUMMARY 


Configuration  management  is  defined  as  the  management  of  change. 
This  paper  ijs  about  the  use  of  an  integrated  Programming  Support 
Environment  Ain  Software  Configuration  Management.  It  discusses 
the  current  methods  of  software  configuration  management,  and 
how  the  control  of  change  in  evolving^PSE)^ with  an  adequately 
design  database  and  an  integrated  set  of  software  tools.  The 
discussion  is  based  on  the  facilities  to  be  provided  in  the 
database  and  tools  of  the  UK  CHAPSE  (CHILL  Ada  Programming  Support 
Environment) . 
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1.0  INTRODUCTION. 

A  Programming  Support  Environment  (PSE)  is  intended  to 
support  the  development  and  maintenance  of  applications  software 
throughout  the  life  cycle.  Stoneman  (ref.  1)  sets  out  the 
requirements  for  an  Ada  PSE  (APSE!  with  particular  emphasis  on 
software  for  embedded  applications.  It  provides  guidelines 
indicating  the  general  requirements  for  such  a  support  system* 
and  a  propos  software  configuration  management*  it  says: 

1.  "the  APSF  must  enable  c on f i gu r a t i on  control  to  be  maintained: 
for  any  con f i gurat i on  of  software*  it  is  necessary  to  be  able 
to  determine  the  oriqin  and  purpose  of  each  component  of  the 
configuration  and  to  control  the  process  of  further 

development  and  maintenance  of  the  configuration"; 

?.  "PROJECT  T F AM  SUPPORT;  An  APSF  snail  support  all  functions 
renui red  by  a  project  team;  these  functions  include  Project 
management  control*  documentation  and  recording*  and 
long-term  configuration  and  release  control". 

It  is  an  essential  characteristic  of  software  that  it  is 
created  and  maintained  in  various  forms  and  embodiments  durina 
its  life  cvcle.  For  example  initially  the  software  will  exist  in 
the  form  of  a  requirements  specification.  At  a  later  stage  in 
ihe  life  cvcle  the  software  will  include  design  documents  and 
source  code.  Nhen  the  software  development  is  complete  the 
software  will  exist  as  a  set  of  compiled  units  and  as  an 
executable  unit*  plus  a  set  of  acceptance  tests  and  test  results. 

Configuration  management  has  been  defined  by  Dunn  and  Oilman 
(ref.  3)  as  the  management  of  change.  Uurinq  the  life  cycle  of 
a  software  product  the  software  undergoes  Perpetual  change.  That 
change  needs  to  be  controlled  if  the  product  is  to  perform  as 
regu i red. 

Software  configuration  management  techniques  have  been 
developed  piecemeal  in  response  to  a  need  rather  that  as  an 
integrated  set  of  procedures.  This  qives  rise  to  a  number  of 
problems  including: 

1.  difficulty  with  software  r egene r a t i on  *  which  is  often  risky 
or  even  impossible  because  of  insufficient  data  on  how  the 
original  software  was  Put  together* 

2.  difficulty  in  determining  the  product  status  at  any  time* 

3.  difficulty  in  tracinq  the  effects  of  makinq  changes  to  the 
system* 

A.  inadequate  or  non-existent  derivation  histories; 
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5.  confusion  of  the  orioinal  structure  of  the  soitwere  when 
evolution  of  a  software  system  leads  to  unplanned  variants. 


?.0  *HAT  IS  A  SOFTWARE  CONFIGURATION? 

Any  part  of  the  software  may  be  embodied  in  documents  on 
oaoer  as  well  as  in  computer  storage  as  a  file  or  set  of  files. 
Each  of  the  forms  of  the  software  (requirements  specification  to 
executable  code  and  all  the  intermediate  forms)  and  the 
embodiments  (for  example  source  code  listings  and  files  in 
computer  store  containina  the  source  coop)  are  aspects  of  the 
same  thing  and  proper  records  must  be  Kept  showing  how  thev 
relate*  now  they  may  oe  transformed  to  create  other  forms  and 
what  changes  have  been  made  to  them,  if  the  software  development 
and  evolution  is  to  be  controlled  effectively.  The  various  forms 
and  embodiments  of  the  software  that  exist  at  a  given  time  are 
called  the  software  configuration  at  that  time.  Thus  the 
software  configuration  varies  with  time  as  specification,  uesiyn 
and  implementation  proaress.  The  different  forms  and  embodiments 
of  the  different  parts  of  the  software  are  called  software 
configuration  items  (SCls).  The  current  software  configuration 
is  the  current  and  controlled  definition  of  the  software  and 
consists  of  all  SCIs  that  are  sufficiently  stable  to  be  under 
configuration  manaaement. 

The  components  of  a  software  configuration  will  include: 

1.  requirements  documents? 

?.  desiqn  documents; 

3.  program  source  text; 

а.  compiled  code,  linked  compiled  code  and  executable  code; 

5.  user  documents  and  instructions  for  starting  and  recovery 
after  failure; 

б.  compilation,  link  and  load  commands  for  each  version  of  the 
executable  programs,  including  versions  of  the  compiler  etc. 
used; 

7.  ehanaes  reauested  (whether  approved  or  not)*  with  history  of 
authorisations  and  action  taken; 

8.  runnino  environment  (hardware  and  software)  reouireu  for  each 
executable  program; 
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2.2  base  1 i nes. 

A  Daseline  Is  an  approved  list  o f  SCls.  The  development 
plan  foe  a  software  product  will  define  a  succession  of  planned 
baselines  coincident  with  the  reference  points  or  milestones  in 
the  life  cycle.  As  the  development  proceeds  the  definitions  of 
the  baselines  are  refined  until  the  relevant  milestone  is 
reached/  when  the  baseline  is  said  tn  be  established. 

because  several  different  implementations  of  a  product  need 
to  coexist/  there  may  be  several  versions  of  each  baseline.  For 
example/  durinq  product  maintenance  there  will  be  established 
baselines  cor resoondi nq  to  the  current  realisation  of  the  product 
in  addition  to  baselines  for  the  revised  realisation  that  is 
under  development.  The  SCls  in  these  baselines  will  probably 
overlap  to  a  considerable  extent#  because  parts  of  the  system 
will  not  need  to  be  chanaed. 

A  sinale  software  configuration  network  can  cover  all  the 
different  versions  of  the  product.  There  will  be  a  set  of 
baselines  for  each  version  of  the  product. 

The  current  software  configuration  is  usually  defined  by 
reference  to  the  current  baselines  (i.e.  the  most  recently 
established  baselines)  plus  a  list  of  increments  to  those 
baselines.  Alternatively#  it  may  sometimes  be  useful  to  define 
the  current  software  configuration  by  reference  to  the  next 
planned  baseline  plus  a  list  of  deviations  from  the  planned 
baselme#  showing  the  particulars  in  which  the  software 
configuration  at  that  time  deviates  from  the  planned  baseline 
fi.e.  those  SCls  in  the  planned  baseline  that  have  not  yet  come 
under  configuration  management#  and  those  SCls  that  have  come 
under  configuration  management  that  were  not  included  in  the 
planned  baseline  although  they  are  a  Part  of  the  configuration 
for  that  version  of  the  product). 

Both  baselines  and  the  software  configuration  are  controlled 
by  software  con f i gur at i on  management. 

The  following  baselines  are  commonly  used  (refs  2  and  5): 

1.  functional  baseline#  established  prior  to  software 
de vel opment  # 

(mav  include  program  development  plan#  quality  assurance 
plan#  con f i gurat i on  management  plan  and  the  system 
requirement  specification)# 

2.  allocated  baseline#  established  when  the  functions  to  be 
performed  have  been  allocated  to  soecific  hardware  and  software# 

(may  include  the  same  configuration  items  as  the  functional 
baseline#  plus  the  software  requirements  specification  and 
acceptance  test  plans)# 


SOFTWARE  CONFIGURATION  MANAGF MENT  IN  AN  INTEGRATED  PSE 
WHAT  IS  A  SOFTWARE  CONFIGURATION? 


Page  S 


3.  design  baseline#  established  when  the  top  level  design  of 
the  software  is  complete# 

(mav  include  the  sane  items  as  the  preceding  baseline#  plus 
documents  giving  the  functional  breakdown  of  the 
requirement;  the  structure  of  the  software#  descriptions 
of  the  data  and  other  hiqh  level  design  documents#  the 
integration  test  nlan  and  test  procedures); 

.  detailed  design  baseline#  established  when  the  design  of 
the  software  is  complete# 

(may  include  the  same  items  as  the  preceding  baseline  plus 
detailed  design  descriptions  of  each  software  module  and 
system  user  manuals)# 

5.  Product  baseline#  established  when  the  software  is  ready 
for  delivery  to  the  customer# 

(may  include  the  Same  items  as  in  the  preceding  baseline 
plus  source  code;  compiled  source  code#  compiler  and 
loader  reports;  maos  showinq  the  allocation  of  the 
executable  code  to  computer  store  anu  to  firmware; 
executable  program  ana  test  reports#  but  excluding  the 
integration  test  plan  and  the  acceptance  test  plan); 

6.  operational  baseline#  established  on  delivery  of  the 
software  product  to  the  customer# 

(may  include  the  same  items  as  in  the  preceding  Daseline 
except  for  the  program  development  plan  and  the  oualitv 
assurance  plan). 


3.0  WHAT  IS  SOFTwARF  CUNF IGURAT ton  management? 

Software  configuration  management  (Stw)  is  the  discipline  of 
systematically  controlling  changes  to  the  configuration  to 
maintain  the  integrity  and  traceability  of  the  configuration 
throughout  the  software  system  life  cycle  (Ref.  2).  It  is  a 
Part  of  software  product  management  rather  than  software  project 
management#  in  that  it  is  concerned  with  controllino  the  product 
rather  than  the  organisation  that  develops  the  product. 

A  configuration  management  Plan  identifies  all  interested 
parties  and  all  documents  and  computer  files  that  are  to  be 
controlled#  indicates  when  each  item  will  come  under  control#  who 
will  control  the  item#  and  how  changes  are  to  be  made  and 
controlled.  A  software  configuration  item  is  said  to  be 
registered  when  it  has  come  under  the  control  of  software 
configuration  management. 

In  some  organisations  (ref.  12)  there  are  two  levels  of 
control  applied  to  SCIs:  registration  and  bonding.  Bonaen  SCIs 
are  subject  to  stricter  and  more  formal  control  of  changes  than 
is  applied  to  SCIs  that  have  been  reoistered  but  not  bonded.  The 
control  of  bonded  SCIs  involves  approval  of  bodies  external  to 
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the  product  development  organisation.  Changes  to  SCIs  that  are 
registered  but  not  bonded  must  still  be  properly  authorised*  but 
the  bociv  required  to  aive  the  authorisation  may  be  internal  to 
the  product  development  organ i sat i on . 

C on f i au r a t i on  management  has  tour  complementary  functions: 
identification;  control;  auoitinq;  and  status  account ina. 

Confiauration  Identification  involves: 

1.  labelling  each  configuration  item  and  showina  how  the 
various  items  are  combined  to  produce  the  different 
versions  of  the  executable  programs; 

2.  defining  and  updating  the  baselines  and  the  SCI  network; 

3.  maintaining  the  dependencies  in  the  SCI  network? 

<4.  listing  the  current  baselines? 

5.  listing  those  SCIs  belonging  to  each  baseline,  and 
whetner  they  are  bonded  in  that  baseline; 

o.  listing  when  each  registered  SCI  Came  under 

configuration  control  and  when  each  bonded  SCI  was 
ponded; 

7.  listing  the  current  software  configuration,  indicating 
deviations  from  the  baselines  (i.e.  the  SCIs  that  have 
yet  to  be  registered  in  the  baseline?  the  SCIs  that 
should  have  been  ponded  ,  that  have  been  registered  but 
not  yrt  bonded?  and  the  SCIs  that  have  been  registered 
or  bonded  although  not  in  the  Daseline). 


Configuration  control  involves: 

1.  approving  and  monitoring  the  registration  of  objects  as 
SCIs; 

2.  registering  approved  SCIs  (i.e.  creating  and 
maintaining  the  library  of  SC  I  S  )  ? 

3.  approving  and  monitoring  the  bonding  of  registered  SCIs; 

4.  bonding  registered  SCTs? 

5.  approving,  monitoring  and  controlling  changes  to 
registered  or  bonded  SCIs,  (i.e.  making  the 
implications  of  a  proposed  change  visible  prior  to 
change  approval  and  ensuring  that  all  actions  required 
when  changing  the  software  c on f i gu r a t i on  have  been  done. 
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sue N  as  approval  t>v  the  appropriate  body,  completion  of 
arprooriate  tests  and  related  changes  to  all  dependent 
/  configuration  items*). 


Cent iaurat ion  Auditinq  involves! 

1.  sanctioning  a  new  baseline  by  verification  and 
va 1 i dat i on; 

d.  listing  the  ways  in  which  the  new  baseline  differs  from 

the  stated  needs  as  given  in  the  regu  events 

specification  and  design  documents. 

(verification  is  defined  as  checkinq  that  the  new  _«line 
is  a  correct  interpretation  of  the  preceding  base  le  and 
validation  is  defined  as  checkinq  that  the  pri  as 

defined  in  the  new  baseline  meets  the  customers  reqc  -  ents 

(ref.  ?)). 


Con f i ourat i on  status  accounting  involves  recordino  and 
reporting  all  significant  events  in  the  product  life  cycle 
related  to  the  software  conf i ourat i on.  including; 

1.  recording  the  establishment  and  attainment  of  each 
base  I i  ne» 

2,  recording  any  changes  to  the  configuration,  with  reasons 
for  the  changes! 

recording,  controlling  and  actioning  all  defect  reports 
or  change  requests,  (changes  to  registered  or  ponded 
configuration  items  are  usually  controlled  by  renui rino 
the  submission  ana  approval  of  defect  reports  or  change 
requests,  for  every  change  however  trivial). 


4.0  nO*  IS  CONFIGURATION  MANAGEMENT  TRADITIONALLY  ACHTtVED? 

Con f i qu r at i on  management  today  is  a  largely  manual  process, 
involving  cnllectinq  each  configuration  item  into  a  central 
library,  indexina  the  library  and  managing  the  procedures  for 
system  development  and  change. 
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4.1  Development  Uf  A  Configuration  Identification  System. 

The  development  of  a  software  configuration  identification 
system,  with  labelling  conventions  ref  led ina  tne  deoenoencies  of 
the  different  items,  and  matchinq  the  software  design,  is  usually 
a  joint  responsibility  of  software  configuration  management, 
software  quality  assurance  and  product  management.  The  network 
of  dependencies  will  develop  as  the  design  develops. 


4.?  Definition  Of  The  Baselines. 

Baselines  and  the  associated  milestones  are  defined  nv 
project  management  supported  bv  quality  assurance  and 
configuration  management  when  the  software  development  plan  is 
produced.  The  detailed  definition  of  the  content  of  a  baseline 
will  develop  in  step  with  the  software  design. 


4.T  Registration. 

Programmers  and  software  designers  work  on  objects  outside 
the  purview  of  software  configuration  management.  a hen  the 
programmer  or  designer  is  satisfied  that  the  item  is  staple  and 
meets  its  objectives  it  will  i>e  submitted  for  registration  as  a 
software  configuration  item.  The  first  step  is  tne  completion  of 
a  design  review  to  check  that  the  item  meets  its  objectives.  If 
the  item  meets  its  objectives  it  can  be  reois^erej,  togethpr  with 
associated  SCIs  (for  example  a  source  code  item  will  probably  je 
registered  at  the  same  time  as  the  compilation  unit  derived  from 
it,  the  executable  code  in  which  it  was  tested  and  the  test 
results). 


4 . a  bond i ng . 


A  r eg i s  t  e  red  SCI  is 
to  need  further  change 
change  to  an  associated 


bonded  when  it  is  t  ought 
unless  the  change  is  reou 
tern  or  change  to  the  user 


t  o  be  uni  i ke 1 v 
red  because  of 
reou i rement  . 


4.5  Project  Librarian. 

A  project  librarian  is  responsible  for  recording,  storing, 
indexing,  controlling  access  to  and  issuing  reference  copies  of 
all  registered  SCIs.  He  is  also  responsible  for  issuing  change 
information  to  affected  personnel  (e.g.  programmers  responsible 
for  SCIs  dependent  on  a  modified  SCI)  whenever  an  SCI  is 
modified.  He  produces  reports,  for  use  by  project  management  and 
software  quality  assurance,  on  the  current  planned  baselines,  the 
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current  software  configuration,  what  has  been  changed*  and  what 
authorised  changes  have  not  vet  been  implemented.  The  librarian 
is  also  responsible  for  archiving*  and  making  copies  of  all  SCls 
to  ensure  the  integrity  of  the  configuration. 


Q.h  Change  Mechanism. 

During  development  and  maintenance  of  software  it  is 
inevitable  that  changes  will  need  to  be  mage  to  the  software 
configuration*  either  because  of  changes  in  the  requirement  or 
the  taraet  hardware*  or  because  defects  are  discovered  in  the 
desian  or  implementation.  A  mechanism  is  therefore  required  for 
controlling  changes  and  ensuring  that  none  are  overlooked  or 
acted  upon  without  proper  authorisation.  A  formal  met  nod  for 
proposing  changes*  ang  reporting  defects  is  usual*  involving  a 
set  of  forms*  and  required  authorisations.  The  process  entails: 

1.  proposal  of  a  change  (possibly  by  the  user  or  the 

i mp I  ament e r )  ; 

2.  incorporation  of  the  change  proposal  into  a  document  (whether 
or  not  the  proposed  change  is  accepted)* 

3.  review  of  the  proposed  change  by  an  appropriate  authority* 

o .  alteration  to  the  software  configuration  or  planned  baseline 
to  incorporate  the  change  if  it  is  approved. 

For  example*  (refs  2  ang  5)*  the  following  system  mav  be  used: 

1.  when  it  is  believed  that  the  software  may  be  oeficient* 
either  because  of  an  incident  when  running  a  orogram  or  as  a 
result  of  a  design  review  or  other  cause*  a  software  Defect 
Report  is  completed  identifying  the  susnecteo  oefect  and 
giving  reasons; 

2.  Software  Defect  Reports  are  reviewed  and  marked  as  'no  action 

required'*  'deficiency  needs  remedy'  or  'change  in 

requirement  needed'*  (  each  markinq  needs  endorsement  bv  an 
appropriate  authority); 

3.  if  'deficiency  needs  remedy'  then  a  Software  Change  Notice  is 
completed*  that  mav  authorise  a  change  in  documentation*  in 
design  or  in  source  code  and  dependent  SCIs.  The  Software 
Change  Notice  will  list  the  affected  SCls; 

A.  if  'chaooe  in  requirement  needed'  then  a  Software  Change 
Request  is  completed.  Such  ehenqe  requests  may  also  be 
aeoerated  without  a  preceding  defect  report.  Change  requests 
must  be  submitted*  with  supporting  information*  for  formal 
aut hor i Sat i on  by  a  body  suco  as  the  Configuration  Control 
Board; 
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5.  if  changes  in  requirement  are  authorised  then  a  Software 
Chanoe  Notice  may  be  completed*  or  another  form  called  an 
Fnqineerino  Chanoe  Proposal  may  be  required? 

h.  all  defect  reports  and  software  'hanqe  requests  are  archived* 
for  conf i ourat i on  status  account ino.  It  is  the 

responsibility  of  the  project  librarian  to  progress  any 
authorised  changes  and  to  notify  affected  personnel. 

It  is  essential  that  versions  of  an  SCI  that  exist  prior  to 
an  authorised  change  are  retained*  partly  to  support  any 
subsequent  audit*  and  partly  so  that*  for  example*  the 
requirement  spec i f i c a t i on  for  an  existino  product  remains 
available  despite  the  evolution  of  the  specification  into  a  later 
base  1 i ne . 


5.0  AIDS  TO  CONFIGURATION  MANAGEMENT  IN  THt  UK  MCHAPSF. 

An  Ada  Proqrammina  Support  Environment  (APSE)*  as  defined  in 
the  Stoneman  Requirements  (Re*.  1)*  is  intended  to  include 
facilities  to  assist  in  conf i gurat i on  manaqement .  An  integrated 
programming  support  environment  (PSF)  includes  a  computer 
controlled  database  and  a  Set  of  software  tools  (proorams)  for 
manipulating  Ob  i  ec t s  in  the  computer  controlled  database.  The 
database  not  only  acts  as  a  repository  for  all  information 
associated  with  a  project  throughout  the  Project  life  cycle*  but 
also  relates  the  different  objects  to  one  another.  In  fact,  the 
main  difference  between  a  PSF  and  currently  available  collections 
of  software  tools,  provided  for  building  and  controlling  the 
production  of  Software  systems*  is  the  existence  of  an  underlyina 
computer  controlled  database  relating  different  objects 
associated  with  the  development  and  providing  facilities  for 
controlling  relationships  and  dependencies*  together  with  an 
integrated  set  of  software  tools  for  operatinq  on  objects  in  the 
database  and  creating  new  database  objects. 


5.1  UK  mchapSE. 

The  MCHAPSF  (Minima1  CHILL  Ada  Programming  Support 
Environment)  is  heina  developed  in  the  l»K  to  satisfy  the  Stoneman 
requirements.  Refs  10  and  11  describe  the  MCHAPSF  as  it  is 
currently  envisaged. 

The  MCHAPSF  will  include  a  PSt  database  although  its 
software  toolset  is  the  minimum  set  of  tools  needed  to  support 
the  development  of  Ada  end  CHILL  applications  for  embedded 
software.  It  is  the  intention  that  further  tools  be  adqed  to 
transform  the  MCHAPSF  into  a  full  PSF  in  due  course.  It  is  also 
intended  that  these  tools  shall  all  operate  on  the  PSE  database 
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and  communicate  with  the  users  through  a  common  set  of 
interfaces.  The  tools  to  he  developed  will  include  tools  for 
configuration  management .  The  facilities  required  for  software 
configuration  mjnaaement  are  independent  of  the  language  in  which 
the  software  is  implemented. 


5.1.1  Database  Terminology. 


Objects  in  the  mCHAPSE  database  (see  ref.  lo)  are  known  as 
entities  and  relationships.  Entities  are  arouned  into  disjoint 
sets  of  objects  having  common  characteristics.  The  disjoint  sets 
are  called  entity  types.  A  connection  between  two  entities  is 
called  a  relationship.  Relationships  also  belono  to  aisjoint 
sets»  called  relationship  tynes#  that  connect  two  entity  types. 
Both  entities  and  relationships  hdve  attributes  that  represent 
the  properties  of  the  objects.  An  entity  type  is  said  to  nave  a 
role  in  a  relationship  type.  A  relationship  type  «av  be 
identified  by  the  name  of  one  of  the  two  roles. 

A  database  schema  is  usea  to  define  the  structure  of  a 
particular  database#  showing  the  types  of  objects  that  may  exist 
in  the  database#  the  ways  in  which  the  objects  mav  be  relatea# 
the  attributes  they  may  have  and  the  properties  of  the 
attributes#  relationship  types  and  entity  types. 

Diagram  of  a  database  schema#  showing  two  entity  types  connected 
by  a  relationship  type. 


Entities  of  type  El  mav  be  connected  to  entities  of  type  L? 
by  relationships  of  type  Kl# 

The  role  of  entities  of  type  El  in  relationship  type  Rt  is  M» 

The  role  of  entities  of  type  E?  in  relationship  tyre  R1  is  h?# 

Entities  of  type  El  have  attribute  At; 

Fntities  of  type  E?  have  attribute  A 2. 


I  J 
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Instances  of  Database  objects  connected  as  in  the  above  schema: 


CZZ) 


attribute 


el  is  an  entity  of  type  El#  with  value  al  for  attribute  A l ; 

e2  is  an  entity  of  type  F<?#  with  value  a?  foe  attribute  A2# 

e3  is  an  entity  of  type  F2»  witn  value  a3  for  attribute  A2J 

el  is  connected  to  both  e2  and  e3  by  relst  ionsMps#  rl  anu 

r2 #  of  t  ype  R  1  . 


The  tools  that  provide  access  to  the  database  will  ensure 
that  the  structure  and  properties  of  the  database#  as  set  out  in 
the  schema#  are  maintained.  They  also  check  tnat  toe  access 
protection  specified  for  objects  in  the  database  is  not  violated 
and  they  provide  facilities  to  users  for  irainf  ainino  the 
intearity  and  consistency  of  the  database.  In  this  oarer  these 
priveleged  tools  will  be  called  the  database  tools. 

The  core  schema  is  that  cart  of  the  database  schema 
specified  for  the  MCHAPSE  (ref.  11).  It  is  the  mimimum  schema 
needed  to  provide  a  database  to  support  the  MCHAPSE  tools#  in 
Particular  the  compilation  and  linkinq  system.  Any  schema  for  a 
database  to  support  a  full  PSL  based  on  the  mchapsE  will  need  to 
include  the  core  schema  as  a  subset.  Futension  to  the  core 
schema  will  he  needed  to  support  software  configuration 
manaoement . 

The  PSE  database  will  include  objects  that  are  not  under  SCM 
as  well  as  objects  that  are  under  SCM,  The  part  of  the  database 
schema  that  defines  objects  under  SCM  will  be  called  the  SCM 
schema.  The  Part  of  the  database  holding  objects  under  SCM  will 
be  called  the  software  configuration  database. 
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5.1.?  Information  Associated  With  SCIs. 


The  attributes  of  an  entity  contain  the  information  closely 
associated  with  the  entity  such  as  creation  date*  name*  body  (of 


a  text  file  for  example)  or 
Information  less  closely  related 
of  the  person  responsible  for  the 
attributes  of  related  entities  or 


the  history  of  the  entity, 
to  the  entity  (such  as  the  name 
entity)  may  he  held  in  the 
of  relationships. 


5.1.3.1  Mandatory  Attributes. 


A  mandatory  attribute  is  an  attribute  that  every  memoer  of  a 
specified  entity  type  or  relationship  type  must  have.  There  is  a 
set  of  predefined  attributes  that  are  mandatory  for  all  entity 
types  in  the  CHAPSF  database*  and  a  set  of  predefined  mandatory 
attributes  for  all  relationship  types  in  the  CriAPSE  database. 
The  list  of  mandatory  attributes  of  any  entity  type  or 
relationship  type  can  he  extended  to  include  mandatory  attributes 
which  are  not  in  the  predefined  list. 

Some  of  the  predefined  mandatory  entity  attributes  hold 
information  needed  for  software  conf i yurat i on  management*  for 
ex  amp  I e : 

1.  name  of  the  object* 

?,  version  (successor  and  variant)  of  the  object* 

3.  creation  date* 

4.  name  of  person  (author)  who  created  the  object* 

5.  derivation  of  the  object* 

6.  access  controls. 


Some  additional  information  must  be  associated  with  every 
SCI.  For  example*  every  SCI  must  have: 

1.  SCT  identification  of  the  object; 

?.  reason  for  creation  of  the  current  version  of  the  object. 


In  addition*  specific  Kinds  of  SCI  mav  need  to  to  have  other 
information  associated  with  them.  For  example*  a  change  reauest 
must  have  an  attribute  to  hold  the  status  (accepted*  rejected* 
rending)  of  the  proposed  change. 


J 
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The  database  schema  specifies  the  attributes  of  an  entity  or 
of  a  relationship  that  are  mandatory  and  the  database  tools 
ensure  that  entities  and  relationships  are  not  formed  tntn  their 
mandatory  attributes  unset. 

A  tool  for  reoisterina  an  object  as  an  SCI  could  prompt  for 
values  for  the  mandatory  attributes  ana  could  check  that  tne 
values  were  acceptable. 


5. 1.2. 2  Mandatory  Roles. 


Some  information  that  must  be  associated  with  an  SCI  may  be 
better  catered  for  by  lorc'na  the  SCI  to  have  a  aiven  type  of 
relationship  to  another  entity  type  than  by  the  imposition  of 
mandatory  attributes.  For  example#  every  SCI  must  be  the 
responsibility  of  one  person.  The  details  of  the  Person#  such  as 
Qualifications#  department  and  telephone  number  may  be  held  as 
attributes  of  the  person  entity.  Tne  SCI  therefore  needs  a 
relationship  to  one  Person  entity#  inoicatino  responsibility. 

The  database  schema  indicates  the  relationships  an  entity 
must  have  by  specifying  the  mandatory  roles.  The  property  of 
having  mandatory  roles  in  a  relationship  will  be  useful  for 
configuration  management.  They  can  ensure  that  some  of  the 
dependencies  in  the  SCI  network  are  enforced  in  the  database. 
For  example#  an  SCI  must  have  a  relationship  to  the  person 
responsible  for  the  SCI. 

In  addition.  Particular  kings  of  SCI  will  need  other 
mandatory  roles.  For  example#  any  Fnoineerina  Change  Pronosa' 
must  have  a  relationship  to  at  least  one  Software  Change  request# 
to  at  least  one  responsible  person#  and  to  at  least  one  SCI. 


5.1.3  Versions. 


Since  software  is  constantly  being  chanoerl#  any  SCI  may 
exist  in  a  number  of  different  versions,  all  of  which  need  to  be 
retained.  In  addition  to  the  different  versions  related  in  a 
predecessor/successor  fashion#  there  will  be  different  versions 
of  the  same  thing  arising#  for  example#  because  of  variations  in 
the  implementation  of  a  design#  or  minor  differences  between  SC  1  s 
to  cater  for  different  target  hardware  configurations. 

To  assist  in  dealing  with  this  problem  the  CHAPSF  database 
will  provide  two  forms  of  versions#  called  successors  and 
variants#  for  objects  that  have  the  same  name  in  the  database. 
The  variants  represent  different  interpretations  of  an  object# 
such  as  different  implementations  of  the  body  of  an  Ada  package# 
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both  satisfying  the  same  Ada  Package  specification.  The 
successor  versions  of  an  object  describe  an  ordering  of  the 
ooject  representations.  For  example*  the  evolution  of  a  piece  of 
text  may  be  represented  as  a  set  of  successor  versions  of  a 
database  ODiect.  The  successor  representations  provided  for  the 
ChAPSE  form  a  hierarchy*  as  shown  below: 

Diagram  showinq  a  set  of  successors  and  variants  of  a 
single  database  object  with  three  variants*  *»P  and  C 


(  A  ,  1 . 1  ) - ( A  *  1  .2) - C  A*  1  .  3  ) - (  A  ,  1  .  a  ) - (A,  l  .S) 


( A  *  1  . 2 .  l  ) - (  A,1.2.?  ) - (  A, 1.2. 3) 


(T,  1  .?.?) - (f* 1 .2.3) 


Successors  have  numeric  identifiers,  with  hierarchic 
structure  as  illustrated  for  variant  k. 

Variants:  P  is  a  revision  of  (A, 1.3);  C  is  a  revision  of 

(A, 1  .2.2) 


The  entity  has  several  "current"  versions*  vit,  (P*l.«), 
(A, 1.5)i  (A, 1.2. 3)J  CC, 1.2.3). 

It  is  recommended  that  only  a  sinqle  chain  of  successors  pe 
used  for  registered  SCls  to  avoid  confusion  as  to  which  is  the 
"current"  version  of  each  variant. 

Adeauate  precautions  will  have  to  be  taken  to  ensure  that 
the  correct  version  is  used  in  any  software  conf iourat ion.  It 
will  probably  be  necessary  to  name  successor  and  variant 
explicitly  in  any  reference*  rather  than  using  the  default 
successor  and  variant.  The  database  tools  allow  for  a  preferred 
variant  and  a  preferred  successor  to  be  used  as  defaults  if  no 
version  identification  is  given. 


5.1.0  Modification  Of  Registered  SCls. 


Ideally*  once  an  SCI  has  been  registered  it  should  not  be 
modified.  However*  if  a  modification  is  authorised*  it  should 
result  in  the  creation  of  a  new  version  of  the  SCI*  rather  than  a 
change  in  the  attributes  or  re  1  at i onsh i ps  associated  with  the 
existing  version  of  the  SCI.  Even  though  it  will  be  possible  to 
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chance  the  attributes  or  relationships  of  an  entity  in  the 
database  without  creatina  a  new  (version  of  the)  entity  this  is 
not  recommended. 

The  Cw APSE  database  provides  a  facility  whereby  an  object  or 
an  attribute  of  an  object  can  be  bound  (for  details  see  ref.  11 
and  ref.  16).  A  bound  object  or  attribute  cannot  be  deleted  or 
modified.  Changes  to  the  bound  object  can  only  be  effected  by 
creating  a  new  object  or  a  new  version  of  the  object.  Similarly, 
relationships  can  be  bound  so  that  it  is  impossible  to  destroy 
tne  relationship  between  two  entities  as  Iona  as  both  entities 
exist.  The  property  of  binding  can  be  used  to  prevent 
modification  to  or  deletion  of  registered  SCIs.  Rinding  is 
imposed  on  an  entity  or  its  attributes  or  its  relationships  py 
the  creation  of  a  relationship#  defined  in  the  database  schema  to 
have  the  binding  property.  between  the  entity  and  some  other 
entity. 

In  order  to  impose  the  binding  reQuired  on  SCIs  it  will  ce 
necessary  to  represent  an  SCI  bv  a  network  of  entities  and 
relationships,  rather  than  by  a  single  entity  in  the  database. 


*5.1.5  Copying  SCIs  And  Creating  New  Versions  Of  SCIs. 


hhen  SCIs  are  to  be  issued  for  amendment.  or  when  new 
versions  are  to  be  created.  all  the  reouired  attributes  and 
relationships  must  be  carried  forward  into  the  new  entity.  Since 
SCIs  may  be  represented  in  the  database  by  a  network  of  entities 
and  relationships.  rather  than  by  a  single  entity.  the 
preservation  of  the  information  associated  with  the  SCI  may  be 
compl i cated. 

The  CHAPSF  provides  facilities  for  creating  a  new  version  of 
an  entity  (called  revision)  or  for  creating  a  separate  copy  o* 
the  entity,  with  a  new  name  in  the  database  (called  copying). 
Certain  attributes  ana  relationships  of  the  entity  are 
automatically  inherited  without  change.  Other  attributes  are 
either  given  the  value  "unset"  or  their  new  values  are  specified 
by  the  user  when  the  entity  is  revised  or  copied.  The  database 
schema  specifies  the  attributes  and  relationship  types  that  are 
inherited  by  members  of  an  entity  type.  A  tool  will  be  needed  to 
issue  copies  of  SCTs  for  amendment,  with  the  necessary  attributes 
and  relationships  preserved  but  with  some  of  the  bindinq 
rel at i onsh i ps  deleted,  and  with  changed  access  protection. 

The  facilities  in  the  ChAPSE  database  only  allow  a  new 
version  of  an  existing  entity  to  be  added  to  the  database  py 
revision  from  an  existing  version  of  the  entity.  Since  an 
amended  SCI  entity  should  be  added  to  the  software  configuration 
database  as  a  successor  or  variant  of  the  original  SCI  entity, 
the  tool  that  issues  an  SCI  entity  for  modification,  and  the 
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re-regi st rat i on  tool >  must  revise  the  SCI  to  be  issued  rather 
than  copying  to  a  new  name.  The  issued  entity  may  be  a  nee 
variant  of  the  oriqinal  SCI. 

When  a  reai stored  SCI  is  issued  so  that  an  authorised 
amendment  can  be  m ade#  the  copy  will  probably  go  through  several 
versions  oefore  the  amended  SCI  is  ready  for  re-regi st rat i on.  It 
will  be  advisable  to  divorce  the  SCI  versioning  from  the 
versioning  of  the  issued  copy  to  avoid  unnecessary  confusion. 

Piayram  shoeing  a  set  of  successors  and  variants  of  a  an  SCI. 


(C,  1 


(C,  PI¬ 


TS,  o) 


The  SCI  has  two  variants#  C  for  the  controlled  variant  and 
CS  for  the  issued  variant  which  is  not  under  configuration 
management . 

Successors  have  numeric  identifiers. 

Variants;  CS  is  a  revision  of  (C#3)#  that  aoes  tnrouqh 
several  successors  before  it  is  reagy  for  re-regi st rat i on.  (C»«) 
is  a  revision  of  (CS»b)»  created  when  (CS#6)  is  re- r eg i s t e red  a* 
a  successor  of  (C#3). 

when  fCS/6)  has  been  re-registered  as  (C#'0#  the  successor 
chain  for  the  CS  variant  can  be  deleted#  since  it  is  not  under 
configuration  management. 


5.1.6  Uniqueness  Of  Entities. 


Entities  in  the  database  are  usually  distinguished  by  naminq 
the  entity  type,  entity  name#  successor  and  variant.  nowev«r# 
since  many  independent  users  may  share  an  entity  type#  each  with 
their  own  entity  naming  conventions#  it  is  possible  that  more 
than  one  entity  in  a  single  entity  type  will  share  the  same  name# 
successor  and  variant.  Ambiauity  caused  by  sharing  a  name  is 
normally  avoioed  because  entities  are  found  by  Searching  (see 
re f.  16)  via  other  entities  and  relationships#  from  a  known 
entity  or  set  of  entities.  If  different  users  have  chosen  the 
Same  name  for  different  entities  in  the  Same  entity  type#  the 
entities  and  re  1  at i onsh i os  throuoh  which  they  can  be  reached  will 
usually  be  different.  Entities  with  the  same  name  can  also  be 
distinguished  from  each  other  by  the  values  of  other  attributes. 
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Since  finding  a  set  of  entities  when  only  one  entity  was 
expected  could  lead  to  confusion,  there  is  a  facility  to  specify 
in  the  database  schema  that  an  entity  performing  a  specified  role 
in  a  given  relationship  has  the  'unioue  naming  property'.  This 
means  that  when  searchina  via  that  relationship  type,  from  a 
unique  entity,  the  values  of  entity  type»  name,  successor  and 
variant  will  be  sufficient  to  identify  at  most  one  entity. 

This  property  may  be  important  when  setting  up  a  database 
schema  for  con f i gurat i on  «anaoe»ent  »  to  prevent  confusion  caused 
by  accessing  a  set  of  entities  when  only  a  single  entity  was 
reau i  reel. 


S.1.7  History. 


I  he  history  of  every  SCI  (i.e.  all  information  relevant  to 
the  creation  of  the  object)  is  needed  for  configuration  status 
accounting.  Every  database  object  must  have  a  mandatory  history 
attribute  that  "shall  contain  sufficient  information  to  provide  a 
basis  for  comprehesiv#  configuration  control.  Any  necessary 
constraints  shall  be  imposed  on  datahase  operations  so  that  the 
validity  and  consistency  of  history  attributes  is  ensured." 
f  S  t  oneman ) .  The  history  attribute  is  called  derivation  in  the 
ChAPSE  . 

In  addition  to  derivation  it  is  recommended  that  all  SCIs 
have  a  mandatory  attribute  to  hold  the  reason  for  the  creation  of 
that  version  of  the  SCI,  with  references  to  relevant  change 
reauests  if  appropriate.  Registration  tools  could  prompt  for  the 
reason  when  an  SCI  is  reaistereo. 

It  is  intended  that  all  PSE  tools  shall  rerora  derivations 
of  any  object  that  they  create  or  amend. 


5.1.P  Reconstruction  Of  SCIs. 

It  is  necessary  for  con f i qurat i on  management  that  mechanisms 
be  provided  whereby  all  database  objects  needed  to  recreate  a 
specified  object  are  maintained  in  the  database  as  long  as  the 
specified  object  itself  remains  in  the  database.  This  means  that 
it  will  not  be  possible  to  delete  from  the  database  any  SCI 
necessary  to  the  recreation  of  another  SCI.  It  is  expected  that, 
with  the  exception  of  text  files  modified  by  the  Editor,  it  will 
always  be  possible  to  recreate  an  entity  from  th#  derivation 
information.  Derivations  will  probably  include  reference  to  the 
version  of  the  tools  used  to  create  or  amend  the  entity  (e.g. 
the  compiler  «nq  linker  that  were  used  in  the  creation  of 
compiled  objects  and  linked  compilations  from  source  files),  to 
command  files  and  to  input  data  files  needed  for  the  recreation 
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of  the  entity.  In  addition  to  derivation  certain  objects  in  the 
database  will  have  a  steering  file  attribute  that  may  hold  the 
commands  used  when  the  object  was  created. 

Given  a  program  or  partial  link  it  will  be  possible#  using 
derivations  and  steering  file  attributes#  to  discover  the  names 
and  versions  of  any  intermediate  components#  and  source  entities# 
and  names  and  versions  of  the  tools  used  to  create  or  to  modify 
them. 


The  binding  characteristic  may  be  used  to  prevent  deletion 
of  or  amendment  of  objects  needed  for  reconstruction.  The 
transmission  of  binding  through  a  chain  of  objects  each  of  which 
is  necessary  to  the  creation  of  the  next  Object  in  the  chain  is 
important  in  this  context. 

For  example#  the  existence  of  a  binding  relationship  between 
a  linked  program  and  its  constituent  parts  can  prevent  change  to 
or  deletion  of  the  compiled  parts.  The  relationship  between  each 
compiled  part  and  the  source  code  from  which  it  derived  can  in 
turn  bind  the  source  code.  The  relationship  between  the  source 
code  and  the  design  specification  of  which  it  is  an 
implementation  can  bind  the  design  specification. 

when  source  code  entities  are  compiled  in  the  mchaPsF#  the 
source  code  entities  and  the  boav  attribute  of  the  entities  (that 
holds  the  actual  source  te*t 1  are  bound  until  the  compiled  entity 
is  deleted. 

when  an  SCI  is  reoistered  the  registration  tool  will  nee a  to 
create  the  network  of  binding  relationships  needed  to  bind  the 
SCT  and  the  objects  on  which  it  deoends#  such  as  those  needed  for 
its  reconstruction. 


5.1.9  Dependencies  Petween  Ada  Compilation  Units. 


The  Ada  separate  compilation  system  (see  Ref.  15)  allows 
several  separately  compiled  units  to  be  combined  in  an  executable 
program.  Package  and  task  specifications  may  be  compiled 
separately  from  the  corresponding  bodies.  With  the  separate 
compilation  facility#  several  separately  compiled  entities  may  be 
interdependent.  It  will  not  be  possible  to  delete  a  compiled 
unit  from  the  database  while  other  units  exist  in  the  database 
that  depend  on  the  unit  to  be  deleted. 

The  Ada  language  definition  (ref.  17)  reouires  that  if  any 
compiled  unit  is  changed#  all  the  units  dependent  on  the  compiled 
unit  must  be  marked  as  invalid  so  that  they  may  be  recompiled. 
Invalid  compiled  units  must  be  recompiled  before  they  can  be 
linked  to  the  new  version  of  the  compilation  unit.  The  user  of 
the  MCHAPSF  will  be  offered  assistance  such  as  a  listing  of  units 
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that  have  been  invalidated  by  a  compilation,  anH  helo  with 

recoup! lino. 

The  following  dependencies  are  relevant: 

1.  a  specification  or  body  is  dependent  on  a  library  unit 
specification  if  the  source  of  the  compilation  unit  quotes  a 
'with'  clause  (in  this  context  a  library  unit  is  another  unit 
that  exists  in  the  database? 

?.  the  body  of  a  separately  compiled  in-line  suoorogra*  is 
dependent  on  the  body  of  the  compilation  unit  in  which  tne 
Subproqrem  is  defined# 

3#  a  body  depends  on  its  specification; 

<1 .  subunit  bodies  depend  on  their  parent  bodies# 

5.  a  body  or  specification  that  instantiates  a  separately 
compiled  generic  body  is  dependent  on  the  aenerie  body#  which 
may  be  supplied  in  several  separately  compiled  parts# 

6.  a  Partial  link  is  dependent  on  all  its  constituent  parts# 

7.  a  program  is  dependent  on  all  its  constituent  Parts. 


This  requirement  aoes  a  long  wav  to  ensurina  the  integrity 
of  executable  programs#  but  it  is  not  sufficient  for  total 
control  of  dependencies#  since  dependencies  such  as  a  source  code 
file  being  dependent  on  documentation  must  also  be  controlled. 


5.1.10  Sharing  Compiled  Code  Between  Products. 


It  may  sometimes  be  desirable  to  share  compiled  code  between 
different  products  usinq  the  same  database#  or  between  different 
programs  within  a  project.  This  will  be  the  subject  of  another 
naoer . 


5.1.11  Acquisition  Of  Entities  From  Another  Database. 


If  software  is  to  be  reused#  libraries  ere  to  be  shared  or  a 
software  project  is  to  be  undertaken  in  physically  different 
locations#  it  will  be  necessary  to  acquire  software  from  external 
sources.  The  acquired  software  will  need  to  be  incorporated  into 
the  database  and  the  necessary  entities  and  relationships  will 
need  to  be  set  up.  This  will  be  the  subject  of  another  oaoer. 
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*»  .  2  PSE  Tools. 

A  PSE  includes  an  extensible  set  of  software  tools 
(programs )  for  operating  on  objects  in  the  database. 


MChAPSC  Tools. 


The  MCHAPSE  tools  will  provide  the  minimum  set  of  machine 
independent  facilities  that  enable  a  programmer  to  develop  Aga 
and  ChIlL  software  conveniently.  All  access  to  objects  in  the 
database  will  be  made  via  the  privileged  MChAPSL  tools  that 
enforce  the  database  characteristics  described  above*  such  as 
binding*  mandatory  attributes  etc..  They  also  provide  tne 
facilities  such  as  checks  to  prevent  violation  of  access 
controls*  and  transaction  manaoement  to  assist  in  maintaining  the 
infearity  of  the  database  (see  below).  These  tools  can  be  used 
by  any  tool  in  the  PSt. 

The  MCHAPSE  toolset  will  include  the  tools  necessary  for 
creating  entities  such  as  text  objects*  for  compiling  and  linking 
programs  and  parts  of  programs  written  in  Ado  or  CHILL*  with  the 
characteristics  described  above  for  keepinq  control  of 
interdependencies*  for  runninq  a"J  testing  programs  and  for 
developing  new  tools. 


5.?.?  Facilities  Provided  by  The  Database  Tools. 


Access  Controls. 


Access  to  entities*  relationships  and  attributes  will  oe 
controlled*  in  the  CHAPSE*  to  alio*  only  authorized  access.  The 
access  allowed  to  database  objects  is  indicated  by  the  access 
attributes  of  each  object  and  can  be  set  individually  for  each 
entity*  for  each  relationship  and  for  every  attrioute.  Access  is 
restricted  according  to  the  identity  of  the  user  requesting 
access*  and  in  certain  cases  according  to  the  tool  being  used  to 
obtain  access.  The  details  of  the  access  controls  are  discussed 
in  Kef  lf>. 

The  complex  system  of  access  controls  will  aid  configuration 
manaoement  by  enforcing  the  use  of  appropriate  tools  to  access 
registered  SGIs.  It  may  also  be  useful  to  provide  the  project 
librarian  with  special  permits  giving  the  librarian  greater 
access  to  registered  SCIs  than  accorded  to  other  users. 
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5. 2. 2. 2  Transaction  Management. 


Transaction  management  is  a  Facility  whrreoy  a  user  can 
specify  that  a  certain  sequence  of  operations  on  the  database 
shall  He  performed  either  completely  or  not  at  all.  The  user 
defines  the  sequence  of  operations  to  he  so  treated  as  a 
transaction.  In  effect  he  is  then  asserting  that  if  the  database 
was  consistent  at  the  start  of  the  transaction  it  will  still  oe 
consistent  on  completion,  even  if  it  is  inconsistent  at  some 
Stage  ourina  the  transaction.  The  database  tools  will  ensure 
that  if  a  transaction  fails  to  complete,  the  database  is  returned 
to  the  state  it  was  in  before  the  transaction  had  commenced. 

It  will  be  essential  to  use  transaction  management  when 
updating  the  software  configuration  database,  to  prevent  partial 
entry  into  configuration  control  of  configuration  items  that 
consist  of  more  than  one  entity  or  relationship,  and  to  prevent 
creation  of  a  relationship  that  binds  an  attribute  until  the 
attribute  has  had  the  required  value  assigned  to  it. 


5.2.2. 3  Archiving. 


Facilities  will  be  provided  in  the  KCHAPSE  for  1 onq  term 
archivinq  of  database  entities  and  their  relationships.  This  is 
a  vital  function  for  configuration  status  accounting,  which  will 
he  needed  by  the  project  librarian. 


5.2.3  Other  PSE  Tools  For  Configuration  Management. 


A  data  dictionary,  which  is  a  database  holding  descriptions 
of  the  entity  types  and  relationship  types  in  the  main  database 
will  be  available  for  the  development  of  tools  for  the  production 
of  software  configuration  management  reports.  It  can  include 
useful  aliasing  information  and  cross  ref erenc i na  information  as 
well  as  descriptions  of  the  meanino  of  the  different  kinds  of 
database  objects,  attributes  ano  structures.  It  can  also  include 
cross  reference  information  showing,  for  example,  the  tools  that 
use  each  part  of  the  database  and  the  people  that  require  the 
different  reports. 

A  query  language  for  the  PSF  database  might  use  the  data 
dictionary  and  wculd  be  very  useful  for  the  production  of 

reports . 
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h.O  DESIGNING  THE  SCM  SCHEMA. 

It  is  important  that  a  database  schema  be  devised  that  takes 
f ul 1  advantage  of  the  available  database  p cone e t i es .  It  will 
r»eea  to  be  an  extension  of  the  core  database  schema  proposed  for 
the  MChAPSE  which  includes  the  schema  for  the  compilation  and 
linkinq  system.  The  core  database  schema  clearlv  provides  an 
excellent  start  my  point  for  an  SCM  schema. 


b.l  Choice  Of  Entity  T.pes  And  Relationship  lypes. 

The  decision  as  to  whether  different  kinds  of  object  havinq 
common  charsc t er i s t i cs  should  be  represented  by  a  single  entity 
type»  or  by  a  numoer  of  different  entity  types/  is  a  difficult 
one.  For  example/  there  are  many  different  kinas  of  object  whose 
most  important  attribute  is  a  text  file.  These  objects  will  have 
various  different  functions  (e.o.  Ada  source  text/  command 
files/  different  kinds  of  documentation).  Potentially  this  could 
be  reflected  py  havina  several  different  entity  types  for  the 
different  kinds  of  text  object.  The  benefits  would  include: 

1.  tools  that  on  1 v  accept  input  from  appropriate  entity  types; 

?.  the  ability  of  database  tools  to  prevent  illegal 
relationships  between  different  text  entity  types; 

t .  the  facility  for  a  user  to  determine  the  classification  of  a 
te*t  entity  without  examinina  its  contents; 

4.  the  possibility  of  defining  different  attributes  for 
different  text  entity  types. 


The  di sadvant aoes  would  include; 

1.  no  direct  facility  for  copying  between  entity  types  in  the 
database/  (it  would/  however/  oe  Possible  to  write  a  tool  to 
copy  the  attributes  of  an  entity  from  an  entity  of  one  entity 
type  to  an  entity  of  another  entity  type.  It  would  be 
necessary  to  check  that  the  appropriate  re  1  at i onsh i ns  and 
bindinqs  were  established  for  the  new  entity.); 

2.  the  need  to  modify  the  Database  schema  to  accomodate  any  new 
text  entity  type/  with  all  the  concomitant  problems; 

3.  the  potential  proliferation  of  text  entity  types  addinq  to 
the  c omp lexity  of  the  database  sene m, a; 


a 


the  use  of  a  particular  text  entity  for  more  than  one  Purpose 
(e.y.  a  desicin  document  may  contain  some  Ada  source  text  or 
extracts  from  documents  of  one  kind  mioht  be  used  within 


SOFTWARE  CONFIGURATION  MANAGEMENT  IN  AN  INTEGRATE 0  PSE 
DESIGNING  THE  SCM  SCHEMA. 


Raoe  2« 


documents  of  another  kind). 


In  view  of  the  disadvantages  listed  above#  tr>e  cone  dataoase 
schema  proposed  for  the  MCtiApSL  (pef.  11)  caters  for  only  one 
entity  type  for  text  objects#  TEXT#  with  a  single  attribute 
holding  the  body  of  the  text.  It  is  not#  however#  necessary  that 
the  SCM  schema  restrict  itself  to  a  single  entity  type  for  text 
objects#  provided  t  h  a  t  objects  such  as  source  text  that  are  used 
by  MCmAPSE  tools  are  retained  in  the  entity  type  defined  for  them 
in  the  core  database  schema. 

The  differences  in  the  different  kinds  of  TEXT  entity  all 
he'ongina  to  the  same  entity  type  can  be  identified  by  the  role 
the  entity  plays  in  various  relationships  with  other  entities  in 
the  database.  For  example#  if  TEXT  entity  S  is  a  source  file 
that  realises  a  desiqn  dor umented  in  TEXT  entity  D,  then  a 
relationship  may  exist  between  S  and  0  in  which  S  plavs  the  role 
"realises"  and  0  plavs  the  role  "design". 


real i ses 


design 


6.2  Choice  Of  Attributes  And  Relationship  Types  For  A  Given 

Entity  T  ype. 

Information  can  be  associated  with  an  entity  either  directly 
by  being  contained  in  an  attribute  of  the  entity#  or  indirectly 
by  being  contained  in  an  attribute  either  of  a  relationship  of 
the  entity  or  of  another  entity  connected  to  the  given  entity  dv 
a  relationship.  The  decision  as  to  how  the  information  will  be 
associated  with  an  entity  will  depend  to  some  extent  on  the 
strength  of  the  association#  and  the  extent  to  which  the 
information  has  meaning  independent  of  the  entity 


6.3  Dependencies  And  Design  Of  The  Database  Schema. 

Entities  in  the  software  development  system  will  depend  on 
each  other  in  a  variety  of  different  ways.  For  example#  there 
are  the  dependencies  (already  catered  for  in  the  mChApse  database 
schema  for  the  domain)  of  compilation  units  on  each  other  and  on 
source  code  entities.  There  are  also  dependencies  of  designs  on 
requirements#  of  test  results  on  test  data  and  on  the  entity 
under  test#  of  software  entities  on  personnel  entities  and  the 
dependencies  implicit  in  the  SCI  network.  The  SCM  schema  needs 
to  be  designed  to  enforce  certain  dependencies  by  using  mandatory 
relationship  roles#  to  prevent  the  accidental  deletion  or  change 
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of  entities  on  which  other  items  depend  by  the  use  of  Di'ndinq# 
end  to  provide  for  the  tracing  of  dependencies  uv  definition  of 
appropriate  relationship  types. 


6.u  Content  Of  The  SCM  Schema. 

This  e«ample  is  intended  to  illustrated  the  features  of  a 
software  configuration  management  database.  It  is  not  intended 
t  o  be  c  omp 1 e  t  e . 

The  database  will  include: 

1.  a  skeleton  network  of  SCN  entities  representing  the  planned 
SCI  network#  with  rel »t i onsh ins  represent ina  the  connections 
in  the  network. 

2 .  baseline  entities,  with  relationships  to  every  SC N  in  the 
baseline.  perhaps  using  successors  and  variants  to  represent 
the  different  versions  of  successive  baselines. 

a  rroduct  entity  related  to  every  baseline  entity  associated 
with  the  product 5 

U .  entities  holding  the  body  of  each  SCI  object  such  as 

specifications.  plans,  source  code  etc...  with  relationships 
qiving  the  connections  between  them; 

5.  relationships  connecting  the  network  of  SCM  entities  to  the 
entities  holdino  the  body  of  each  registered  SCI.  (these 

relationships  will  be  created  on  registration  of  the  0C1.  and 
will  bind  the  body  of  the  SCI). 


SCN  entities  are  connected  in  the  skeleton  SCI  network 
described  above.  The  actual  objects  to  be  registered  as  Part  of 
the  software  configuration  are  called  SCIS.  Un  registration  of 
an  SCI  a  binding  relationship  will  be  created  to  precisely  one 
SCN  ent i t  y . 

The  database  facilities  provided  in  the  mCHAPSE  do  not 
permit  the  Searching  for  all  entities  in  a  oiven  configuration 
unless  thev  have  some  other  attribute  in  common.  It  will 
therefore  be  useful  to  provide  a  product  entity  connected  to  all 
baseline  entities  associated  with  the  product. 
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produc t 


base  1 ines 


network 


SC  T  s 


fe .  A  .  1  Objects  Under  SCM. 


Many  kinds  ot  object  will  need  to  be  catered  for  in  any 
software  configuration  database.  Some  will  be  catered  for  by 
entities  and  some  by  relationships.  It  may  be  that  several 
different  Kinds  of  object  can  most  usefully  be  catered  for  py  a 
single  entity  type. 

It  does  not  seem  likely  that  the  database  schema  will  use 
different  entity  types  for  reoistered  and  non  registered  SCISr 
because  of  the  difficulty  of  grant inq  appropriate  access  to  tools 
for  compilation  and  linking. 

The  following  kinds  of  object  need  to  be  considered: 

I.  Software  documentation  objects: 

1.  reouirements  documents? 

?.  desian  documents  with  relationships  to  the  supporting 
reoui rement  s  * 

3.  user  documents? 

A.  instructions  for  startinq  and  recovery  after  failure? 

S.  runni nq  environment  (hardware  and  software)  reoui red  for 
each  executable  program.; 
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2.  Compilation  associated  objects: 

1.  program  source  text  with  re  1  at i onsh i ps  to  suprort ino 
desian  documents? 

? .  comp i l ed  cod e? 

3.  linked  compiled  code? 
executable  code? 

5.  compiler  and  loader  reports? 

6.  maos  showing  the  allocation  of  the  executable  code  to 
computer  store  and  to  firmware? 

7.  compilation,  link  and  load  commands  for  each  version  of 
the  executable  programs#  including  versions  of  the 
compiler  etc.  used.? 

3.  Test  associated  oojects: 

1.  database  of  test  data  and  expected  results? 

2.  test  procedures? 

3.  record  of  actual  test  results.? 

A.  Manaaement  objects: 

1 .  oroduc  t  entity? 

?.  SCI  network  (of  SCN  entities)? 

3.  baselines  for  each  milestone#  and  each  version  of  the 
produc  t  ? 

A.  product  development  plan# 

5.  duality  assurance  plan? 

6.  configuration  management  plan? 

7.  acceptance  test  plans? 

9.  integration  test  plan? 

R.  personnel  associated  with  a  project? 

10.  bodies  able  to  authorise  registration  and  bondina  of  SCls 
with  relationships  to  members  of  the  todies.? 
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5.  Change  control  objects: 

1.  Software  Defect  Report#  with  substance  of  the  report# 

author#  status#  and  relationships  to  person  responsible 
for  responding  to  the  reoort  and  to  other  defect  reports 
covering  the  same  fault# 

2.  Software  Change  Reauest#  with  substance  of  the  change# 

author#  status#  relationships  to  bodies  who  neeo  to 

authorise  the  request  and  relationships  to  affected  SCIs# 

3.  Software  Change  Notice#  with  status#  relationships  to 

affected  SCIs#  relationships  to  Software  Change  Requests 
and  Software  Defect  Reports  if  appropriate# 

0.  Engineering  Change  Proposal#  with  relationship  to 
Software  Change  Reauest.. 


The  successor  and  variant  system  of  versioning  will  need  to 
be  worked  out  to  match  the  version  labelling  of  SCIs  ana  SCNs. 


fe.4.2  Character i st i cs  Uf  Objects  Under  SCM. 


The  different  characteristics  of  entities  in  the  database 
can  be  catered  for  by  attributes  or  by  relationships  to  other 
entities. 


The  mandatory  predefined  entity  attributes  that  give 
derivation#  date  of  creation  and  last  amendment  ana  name  of  user 
who  created  the  entity  and  who  made  the  last  amendment  will 
provide  for  some  of  the  needs  for  configuration  status 
accounting#  although  it  is  likely  that  more  of  the  history  of  a 
project  will  need  to  be  kept  than  will  appear  in  these 
attributes.  A  reason  attribute  to  hold  the  reason  for  any  change 
made  to  the  configuration  could  also  be  of  value.  Tools  could  be 
required  to  write  to  a  Conf i qurat i on  Status  Accounting  entity  or 
attribute  every  time  anything  is  done  to  any  item  associated  with 
the  conf i gurat i on  of  the  software. 

The  SCN  entities  will  need  the  following  c harae t er i s t i cs : 

1 .  SC  I  i dent i f i er « 

2.  status  of  the  SCI  (registered  or  bonded)  and  date  on  which  it 
achieved  that  status#  held  as  attributes  of  relationships 
between  the  SCN  and  the  SCI# 
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3.  relationships  to  the  bodies  by  whom  authorisation  for 

real st rat i on/bondi ny  can  be  granted  (the  relationships  can 
have  the  status  and  date  attributes  to  show  whether  and  when 
reoistration  and  bonding  have  been  approved); 

relat lonships  to  each  baseline  entity  if  the  SCI  is  a  member 
of  the  baseline  (the  relationship  can  have  an  attribute  to 
show  whether  the  SCI  is  bonded  or  registered  in  that 
base  1 i ne ) . 


The  reaistered  SCIs  will  need  to  have  the  followina 
characteristics#  (in  addition  to  the  mandatory  predefined  entity 
attributes): 

1.  kind  of  object  (where  an  entity  type  caters  for  more  that  one 
kind  of  object)# 

2.  relationships  binding  all  objects  and  attributes  on  which  the 
SCI  depends  (this  dependence  may  ne  of  the  form  'A'  is  needed 
to  recreate  'b'#  or  a  more  general  form  of  dependence  whereby 
a  change  in  'A'  implies  a  possible  need  for  a  chanae  in 
•B'  .  ); 

3.  a  relationship  to  the  SCN  entity#  bindino  the  significant 
attributes  and  relationships  of  the  SCI  to  prevent  amendment 
of  the  attributes  or  deletion  of  the  relationships; 

a.  mandatory  relationship  to  the  database  object  representing 
the  person  responsible  for  the  SCI. 


fe.S  Example  Of  Part  Of  An  SCM  Database. 

This  example  is  intended  to  illustrated  the  use  of  binding 
and  of  the  skeleton  SCI  network. 

Let  there  be  an  entity  t ype  containing  the  SCNs  and  another 
entity  type  containing  the  baselines  and  let  the  SCI  network 
connections  be  represented  by  relationships  (NET)#  with  roles 
"supports"  and  "deoendson". 
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A  database  for  an  SCI  network  is  shown  below: 


Suppose  that  TEXT  is  the  entity  type  containing  objects  that 
have  text  attributes*  including  requirement  spec  i  f  i  c  a  t  i  ons  * 
desian  specifications  and  source  text*  and  suppose  that  the 
following  relationships  can  connect  TEXT  entities  to  each  other: 

1.  relationship  type  RH  connecting  requirement  specifications 
Crole  "req")  to  designs  (role  "meets")* 

?.  relationship  type  PG  connectina  source  code  (role  "impl")  to 
designs  (role  "des")* 


Suppose  also  that  the  role  "meets"  is  a  binding  role,  and 
binds  the  entity  and  the  body  attribute  of  the  entity  performing 
the  "req"  role*  and  the  role  "impl"  is  a  binding  role*  and  bings 
the  entity  and  the  body  attribute  of  the  entity  performing  the 
"oes"  role  plus  all  relationships  of  type  Rh  in  wnich  the  bound 
entity  performs  the  "meets"  role. 

In  entity  type  TEXT  there  are  the  following  entities: 

1.  reolsrequi rement  spec  (SC11)* 

?.  deslsdesign  ( SC  111)  to  satisfy  reql* 

3.  source  11 ^source  code  ( SC  1111)  for  one  cart  of  desl* 

A.  sourcel 2*source  code  (SCI112)  for  another  part  of  desl. 
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The  database  fo r  the  text  entities  is  as  shot>n  below: 


The  existence  of  the  relationship  between  desl  and  sourcell 
binos  desl  and  the  bodv  attribute  of  desl#  anj  the  relationship 
between  desl  and  regl . 

Similarly#  existence  of  the  relationship  between  desl  and 
sourceli?  binds  desl  and  the  oody  attribute  of  desl#  and  the 
relationship  between  desl  and  reol. 

The  existence  of  the  relationship  between  desl  and  redl 
binds  reol  and  the  body  attribute  of  redl. 

Any  attempt  to  delete  reql  or  to  change  the  body  attribute 
of  reol  will  fail  because  of  the  relationship  to  desl  that  in 
turn  is  bound  by  both  the  relationships  between  desl  and  the  two 
source  entities. 

Let  the  relationship  connecting  an  SCN  to  its  registered  SCI 
entity  have  the  roles  "is"  and  "reo"#  where  "is"  binds  the  entity 
performing  the  "reo"  role. 
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As  fach  entity  in  the  text  entity  tvpe  shown  above  is 
registered  the  connection  between  it  and  the  corresoondi nq  SCN 
entity  will  be  created#  thus  binding  the  registered  SCI  as  shown 
below; 


real  is  bound  by  the 
desl  is  bound  by  the 
sourcell  is  bound  by 
sourcel2  is  hound  by 


relationship  to  SCN1  (role  "is"); 
relationship  to  SCN11  (role  "is")# 
the  relationship  to  SC N 1  1  1  (role  "is"); 
the  relationship  to  SCN112  (role  "is"). 


7.0  SOFTWARE  TOOLS  EuR  CONE IGUKAT ION  MANAGEMENT. 


The  database  tools  will  check  that  the  access  controls  are 
enforced  and  will  provide  archiving  and  recovery  facilities.  The 
software  configuration  management  tools  should  always  ensure  that 
all  necessary  authorities  have  been  obtained#  and  all  the 
requisite  information  has  been  supplied  and  is  acceptable#  before 
modifyinn  the  software  configuration  database  or  issuina 
registered  SCIs.  They  should  use  transaction  management  where 
appropriate  to  preserve  the  integrity  of  the  software 
configuration  database  and  should  always  write  the  history 
information  needed  for  conf 1 gurat i on  status  acccounting  into  the 
configuration  database.  They  should  prompt  for  reasons  for  any 
changes#  to  be  stored  in  the  reason  attribute. 


The  tools  for  listing  ano  cataloguing  the  content  of  the 
software  configuration  database  may  be  based  on  a  standard 
database  query  language  and  associated  data  dictionary#  if  such  a 
language  is  developed  for  the  PSE  database. 
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7.1  Access  Controls  And  The  Project  Librarian. 

The  project  librarian  will  normally  be  responsible  for  the 
creation  and  maintenance  of  the  software  configuration  database. 
The  librarian  must  be  the  only  person  having  access  to  registered 
SCTs.  When  an  SCI  is  registered,  the  registration  tool  may 
chanqe  the  access  permits  of  the  S Cl  possibly  restricting  access 
to  special  tools.  The  librarian  will  then  need  a  special  set  of 
tools  that  have  access  authority  to  operate  on  registered  SCIs 
with  restricted  access  rights. 


7.?  Configuration  Identification. 

Tools  are  needed  to: 

1.  enter  and  update  the  configuration  management  plan,  including 
the  SCI  network,  definition  of  the  baselines  anti  the 
authorities  who  control  changes  to  the  software  configuration 
database, 

2.  print  the  SCI  network; 

3.  list  a  baseline,  with  details  of  when  the  items  came  under 
control  and  whether  or  not  the  items  are  bonded; 

A.  list  the  items  in  a  baseline  that  have  not  yet  been 
reoi stereo; 

5.  show  how  the  various  items  combine  to  produce  different 
versions  of  the  executable  software; 

h.  catalogue  in  various  wavs  the  registered  SCIs,  their 
dependencies,  and  the  associated  entities  and  relationships 
(e.g.  associated  personnel). 


7.?.1  The  SCI  Network  Tool. 


The  SCI  networx  tool  may: 

1.  set  up  the  network  of  SCNs; 

?.  connect  the  baseline  entities  to  the  SCNs; 

3.  connect  the  product  entity  to  the  baselines; 

a,  set  up  the  entities  representing  the  bodies  needed  for  the 
different  kinds  of  aut hor i sat i on  with  re  1  at i onsh i os  to  the 
person  entities  and  to  the  SCNs; 
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5.  provide  facilities  for  extending  and  modifying  the  network  of 
SCNs  as  the  project  progresses. 


7.3  Con f i aurat i on  Control. 

Tools  are  needed  to: 

1.  reaister  new  SCIs#  checkinq  that  the  necessary  authorities 
have  been  obtained# 

2.  bond  SCIs#  checkino  that  the  necessary  authorities  have  oeen 
obt  a i ned# 

3.  list  authorities  required  for  registration  or  bondinq  of  an 
SCI#  or  for  modification# 

A.  list  al I  items  dependent  on  an  SCI  with  details  of  the 

oersonnel  who  need  to  be  informed# 

5.  provide  a  mailbox  facility  to  inform  personnel  of  actions 
reoui red  by  t  hem# 

fe,  Progress  defect  reports  and  change  requests  throuqh  the 

system} 

7.  issue  reference  copies  of  registered  (bonded)  SCIs  as 

aut  hor i sed; 

A.  reregister  amended  SCIs# 

A.  archive  all  registered  and  bonded  SCIs. 


7.3.1  The  Registration  Tool. 

The  registration  tool  may: 

1.  check  that  all  authorities  required  for  registration  nave 
been  granted# 

2.  check  that  all  the  required  tests  have  been  successfully 
per f ormedj 

3.  chenae  the  access  rights  to  the  registered  SCI; 


4 


create  a  binding  relationship  between  the  SCN  and  the  SCI; 
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5.  scan  the  derivation  attribute  of  the  SCI  in  order  to  oiscover 
the  registered  SCls  needing  to  be  related  to  the  new 
registered  SC  I #  and  to  set  up  anv  new  relationships  that  are 
needed# 

6.  write  the  history  information  necessary  for  configuration 
status  accounting. 


7.3.?  The  Bonding  Tool, 


The  bonding  tool  will  be  similar  to  the  registration  tool 
exceDt  that  instead  of  creating  the  binding  relationship  between 
SCI  and  $CN  and  scanning  the  derivation  attribute  it  will  need  to 
modify  the  level  of  control  attribute  of  the  relationship  between 
SCN  and  SCI, 


7.5,?  Change  Control  Tools, 


1. 

?. 


The  change  control  tools  will 
tools  for  progressing  a  Change 
tools  for  the  issue  of  SCls  so 


include  three  groups  of  tools: 
through  its  various  staqes; 
that  changes  can  be  made# 


3,  tools  for  re-registration,  including  any  necessary 

modification  to  steerinq  files  to  cater  for  new  versions  and 
variants. 


The  tools  for  progressing  chanaes  through  the  different  staaes 
mav : 


1.  build  up  a  network  of  re  1  a t i ons h i ps  between  chanoe  documents 
and  the  SCls  to  be  changed#  as  the  change  progresses# 

?.  modify  the  baseline  entities  and  the  network  of  SCNs  to 

accomodate  authorised  change*#* 

3,  list  the  authorisations  required  for  a  given  change#  the  SCls 
affected#  the  People  responsible  and  the  status  of  the 
Change# 

R.  provide  reports  on  changes  to  a  configuration#  such  as 

listina  outstanding  changes#  changes  implemented  for  a 
particular  baseline  etc,# 


i 
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5.  write  the  history  information  necessary  for  configuration 
status  accounting. 

The  tool  for  issue  of  SCIs  may: 

1.  refuse  to  permit  issue  without  the  necessary  authority; 

?.  revise  the  SCI  to  he  modifier),  creating  a  new  version  with  a 
relationship  to  the  Parent  SC i ; 

3.  chanae  the  access  controls  to  the  issued  SCI; 

U.  delete  the  binding  relationships  so  that  the  modifications 
can  be  made. 

The  tool  for  re-registration  may: 

t.  prompt  for  the  reason  for  making  changes,  to  store  in  the 
reason  attribute; 

?.  modify  steering  files  as  appropriate  to  cater  for  changes  in 
version  and  variant  of  the  SCI; 

3.  invoke  the  registration  tool  to  register  the  amended  SCI  as  a 
new  version  of  the  SCI  which  has  been  amended. 


A  useful  tool  has  been  developed  by  Bell  Laboratories,  (ref. 
9)  called  'Modification  Request  Control  System  (mrcs),  that 
provides  several  of  the  facilities  needed  for  change  control. 
MRCS  tracks  and  reports  project  chanoe  reguest s  through 
interactive  input  and  extraction  of  change  reguest  reports  from 
compute  r  tiles. 


7. 3. 3.1  Text  Object  Version  Control. 


There  is  a  tool  developed  by  Pell  Laboratories  that  provides 
some  very  useful  facilities  for  version  control  of  text  objects. 
Called  'Source  Code  Control  System  (SCCS)  (refs.  4  and  13),  it 
provides  facilities  for  storing,  updating  ang  retrieving  all 
versions  of  text  objects#  for  controlling  updating  privileges  and 
for  recording  who  made  each  software  changer  and  when,  where  and 
why  the  change  was  made.  The  control  is  implemented  by  keeping  a 
master  copy  plus  a  set  of  seguenced  deltas  (list  of  changes)  to 
the  preceding  version,  which  uses  less  space  than  keeping  full 
conies  of  each  version.  SCCS  reconstructs  the  reguested  version 
from  the  master  and  the  deltas.  If  a  similar  tool  is  to  be  used 
in  the  PSE  the  re-reoistration  tool  could  be  reguired  to  create  a 
delta  between  a  new  version  of  an  SCI  and  its  predecessor. 
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7.4  Con  f  i  ourat  i  on  Auaitina. 

The  state  of  the  art  in  tools  for  validation  and 
verification  in  the  sense  implied  for  configuration  auditing  is 
not  currently  very  advanced.  However  the  database  could  include 
attributes  detailing  the  findings  of  the  verification  and 
validation  that  has  been  performed.  Tools  could  then  be  provided 
to  list  the  ways  in  which  a  baseline  differs  from  the  needs 
implied  in  earlier  baselines. 


7.5  Con f i au r a t i on  Status  Accounting. 

The  necessary  history  will  be  stored  in  the  database  and 
tools  must  be  provided  for  producing  the  appropriate  reports. 


7.5.1  Recording  Terminal  dialogue. 


because  the  librarian  function  is  so  vital  in  software 
configuration  management,  it  may  be  desirable  to  record  all 
terminal  oia'oaue  between  the  librarian  and  the  system,  so  that 
when  problems  occur  it  will  oe  possible  to  trace  whdt  has 
happened . 


fl.O  SUMMARY. 

Any  Programming  Support  Environment  needs  an  integrated  set 
of  software  configuration  management  tools  that  will,  combined 
with  an  adequately  designed  database  schema,  support  control  of 
the  whole  life  cycle  of  a  software  product. 

The  design  of  a  consistent  and  complete  software 

configuration  manaaement  system  has  three  major  facets: 

5.  judicious  desion  of  an  underlyina  database  schema  to  provide 
the  necessary  network  of  entity  types  and  relationship  types, 
each  having  attributes  appropriate  for  configuration 

manaaement,  using  the  properties  provided  such  as  binding, 
mandatory  attributes  ang  roles  etc., 

?.  selection  of  a  strategy  for  the  use  of  access  permits,  access 
authorities  and  access  riqhts  to  support  control  of  the 
software  configuration  database, 

3.  design  of  appropriate  tools  for  each  aspect  of  configuration 
management#  using  the  transaction  management  facilities  to 
ensure  database  inteoritv. 
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The  SOM  database  schema  needs  to  be  as  indeoengent  as 
possible  of  the  details  of  the  nest  of  the  database  schema  so 
that  the  overall  database  schema  can  be  extended  and*  if 
appropriate*  members  of  the  new  entity  types  and  relationship 
types  can  be  brought  under  SCM  without  redefining  the  oasic  SCM 
database  schema  and  tools. 


8.1  SCm  F unc  t i ons  . 

The  difficulties  implicit  in  developing  software  with 
inadequate  SCM  facilities  are  reduced  when  an  SCM  toolset  is 
integrated  with  the  underlying  software  configuration  database. 


8.1.1  Software  Regeneration. 


The  risk  of  incorrect  software  regeneration  because  of 
inadequate  historic  information  is  much  reduced  by  the  use  of  the 
derivation  attribute*  toaether  with  relationships  to  steerina 
files  and  the  enforced  recording  of  history  by  the  SCM  tools. 


8.1,?  Product  Status. 


The  product  status  at  any  time  will  be  visible  through  tne 
baselines  and  the  change  control  system  toaether  with  tools  for 
listing  and  cataloguing  the  software  configuration  database. 


8.1.3  Effects  Uf  Changes. 

The  effects  of  making  any  proposed  chsnaes  will  be  traceable 
through  the  relationships  in  the  SCI  network  and  the 
relationships  between  registered  SCls.  The  re  1  at i onsh i ps  to  the 
Personnel  responsible  will  ease  the  problem  of  evaluating  the 
results  of  changes. 

The  facilities  for  two  forms  of  versioning  will  prove  useful 
when  building  software  systems  that  must  differ  only  in  some 
small  Particular.  It  will  be  important  to  ensure  that  the 
successor  and  variant  of  any  entity  are  given  explicitly  where 
any  confusion  miqht  arise.  However*  the  use  of  preferred 
successor  and  variant  mav  well  be  useful  in  command  files  for  the 
creation  of  new  entities*  to  remove  the  need  for  change  to  such 
files  when  the  entities  referenced  in  them  are  upuated. 
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9.1.4  Control  Of  Software  Evolution. 


Since  the  tools  can  check  for  prooer  authorisation  of  all 
changes*  it  will  be  easier  to  prevent  the  creation  of  unolanned 
variants. 

SCIs  can  be  forced  to  have  at  least  one  of  any  attributes 
and  re  1  a t i ons h j ps  that  are  deeded  necessary*  by  the  use  of 
mandatory  attributes  and  relationships.  For  e*ample  source  code 
entities  can  be  forced  to  have  at  least  one  relationship  to  a 
design  entity. 


unauthorised  modification  to  or  deletion  of  registered  SCIs 
can  be  prevented  by  binding  ana  bV  access  controls.  The  ability 
separately  to  control  access  to  the  different  parts  of  the 
configuration  database  ana  to  modify  the  access  controls  of 
individual  objects  when  appropriate  is  a  powerful  wav  of 
preventing  unauthorised  access  to  reoisterea  SCIs.  The  fact  that 
access  rights  may  be  different  for  different  users  is  also  useful 
in  that  the  librarian  may  be  oiven  much  more  general  access  to 
reoisterea  SCIs  than  granted  to  any  other  user. 


*.2  Tools. 

It  will  oe  necessary  to  develop  a  special  set  of  tools  for 
configuration  management.  The  transaction  manaaement  facilities 
will  be  used  to  maintain  the  integrity  of  the  software 
configuration  database.  The  tools  will  use  the  relationships  in 
the  database  to  discover  dependencies  so  th»t  the  appropriate 
personnel  can  be  informed  when  changes  are  required.  They  will 
check  that  all  the  necessary  authorities  have  been  obtained  and 
all  necessary  information  has  been  supplied  before  modifvinq  or 
issuina  items  from  the  software  configuration  database.  Ihev 
will  also  ensure  that  adequate  historic  information  is  stored  in 
the  configuration  database  to  satisfy  the  reauirements  for 
reconstruction  of  software  and  for  configuration  status 
account i ng. 

Tools  will  be  needed  for  eacn  of  the  software  cent i gurat i on 
management  functions*  including  tools  for: 

1.  setting  up  and  updating  the  configuration  management  plan 
ineludino  the  base! i nes * t he  SCI  netwo~«  and  the  set  of 
authorities  involved  in  configuration  management  I 

2.  registering  and  re-registering  SCIs* 

3.  issuing  reference  copies  of  specific  registered  SCIs  to 
Authorised  personnel* 
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A.  cataloauing  in  various  ways  the  registered  SCis*  their 
dependencies*  the  associated  SCis  (e.g.  associated 

personne 1  I  * 

5.  establishing  what  is  in  the  current  baseline  and  what  is 
missing  from  a  planned  baseline* 

6.  progressing  software  defect  reports  and  software  change 
notices* 

7.  reoort inq  on  history  and  current  status  of  the  software 
conf i gurat i on. 

The  database  tools  will  provide  the  archiving  facilities 
necessary  for  handling  the  volume  of  data  implicit  in 
configuration  manaoement. 


9.0  CONCLUSIONS. 

The  proposed  MCHAPSF  offers  an  excellent  starting  point  for 
the  development  of  an  integrated  system  for  software 
configuration  management .  The  CHAP3F  database  offers  facilities 
for  defining  a  schema  capable  of  supporting  the  reauirements  of 
configuration  management*  with  the  necessary  re  I  at i onsh i ps 
between  different  kinds  of  SCI*  and  binding  together  with  access 
controls  to  prevent  unauthorised  change  to  the  software 
configuration. 

Good  schema  design,  together  with  the  use  of  a  data 
dictionary*  will  make  it  possible  to  provide  the  various  reports 
needed  for  software  configuration  management  and  will  prevent 
modification  of  or  deletion  of  objects  on  which  other  objects 
depend.  A  standard  P5F  database  query  languaQe*  if  available* 
will  ease  the  production  of  reports. 

Good  tool  design  will  preserve  the  intearitv  of  the  software 
configuration  bv  the  use  of  transaction  management.  The  tools 
can  prevent  registration  or  issue  of  SC  I s  without  proper 
authorisation  and  can  ensure  that  the  history  of  the  evolution  of 
the  software  is  maintained.  Thev  can  produce  reports  to  assist 
in  proper  planning  and  control  of  the  software  evolution  and  can 
provide  facilities  for  change  control*  tracing  through  all  defect 
reports  and  ehanqe  reauests  and  showing  the  i nt erdependence  of 
SCIs. 


The  basic  SCM  schema  and  tools  should  be  designed*  as  far  as 
possible*  to  cope  with  extensions  to  the  overall  database  schema* 
allowing  new  entity  types  to  be  brought  under  SCM  as  required 
without  rewrite  of  the  tools  or  redesign  of  the  SCM  schema. 
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